Skip to main content

Software Engineer PR & Coding Responsibilities Guide

Scope and Responsibilities​

As a software engineer, your role is to contribute high-quality code that fits cleanly into the team's architecture. You are responsible for writing clear, modular, and tested code, while respecting architectural boundaries and escalation protocols.

Time Commitment: 8–10 hours of work per week.

You are expected to:​

  • Follow our service → controller → route structure
  • Handle errors carefully
  • Write clean, readable, and testable code
  • Use AI tools thoughtfully and responsibly
  • Submit at least one PR per week

You are not allowed to:​

  • Modify the Prisma schema (schema.prisma)
  • Run database migrations
  • Install new npm packages
  • Merge code directly to main branches
warning

All schema changes and new package installations must be approved and implemented by one of the four tech leads.

Required File Structure​

Routes: Define only HTTP method and endpoint

Controllers: Validate input, catch errors, and delegate to services

Services: Contain all business logic and database access

Frontend (React):

  • Split logic into hooks and views into components
  • Abstract API calls into /hooks/ folder
  • Use context for state management when needed

PR Approval Checklist​

You must review this checklist before submitting any PR:

Architecture and Structure​

  • Route → Controller → Service flow is followed
  • No business logic exists in routes or controllers
  • Frontend logic is modular and split into hooks/components

Validation and Error Handling​

  • Input validation is handled in controllers (zod or yup)
  • All null/undefined values are properly checked
  • try/catch blocks are present in all external-facing functions

Code Quality​

  • No magic numbers or hard-coded values without explanation
  • Naming is clear, consistent, and follows conventions
  • Code is readable with comments for complex logic
  • No console logs or commented-out debug code

Testing​

  • Unit tests are written for all service functions
  • Edge cases and null inputs are tested
  • React components are tested using react-testing-library where applicable

Test Example​

describe('Users API', () => {
  beforeEach(() => {
    // Reset users data before each test
    app.locals = {};
  });

  describe('GET /api/users', () => {
    it('should return all users', async () => {
      const response = await request(app).get('/api/users').expect(200);

      expect(response.body).toHaveProperty('users');
      expect(Array.isArray(response.body.users)).toBe(true);
      expect(response.body.users.length).toBeGreaterThan(0);
    });
  });
});

PR Content​

  • PR description clearly states the change
  • Includes screenshots for any frontend changes
  • Contains only relevant changes (no unrelated file edits)

Example PR​

Description​

This code adds a new endpoint to create users in our API. The endpoint validates required fields, checks for duplicate emails, and returns appropriate error messages.

Type of Change​

  • New feature (non-breaking change which adds functionality)

Changes Made​

  • Added POST /api/users endpoint in src/routes/users
  • Added validation middleware for user input
  • Added duplicate email check to prevent duplicate registrations
  • Added comprehensive tests for the new endpoint
  • Updated API documentation in README.md

AI Usage Policy​

You may use any AI tool of your choice (we highly highly recommend Claude).

All Claude-generated code must be reviewed, cleaned, and tested before being submitted. You are responsible for the quality of any AI-assisted contribution.

caution

Claude code tends to be extremely verbose and often writes unnecessary code. For example, a method which can be written in 10 lines is written in 100 lines of code by Claude. Make sure to clean and abstract as much as possible.

Permitted Uses​

  • Generating boilerplate code or scaffolds
  • Drafting basic unit test structures
  • Rewriting verbose or repetitive code for clarity

Requirements​

  • All AI-generated code must be manually reviewed and cleaned up
  • Remove bloated logic, redundant checks, or generic abstractions
  • Abstract logic into services or hooks as per team architecture
  • Run and test AI-generated code before submission
  • Ensure full edge-case coverage, especially for tests

Prohibited​

  • Blindly copy-pasting without fully understanding the code
  • Skipping validation, error handling, or null checks
  • Writing AI-generated business logic directly into routes or controllers
danger

If the code appears AI-generated (e.g., overly commented, vague function names, unstructured logic), revise it before submission. You are responsible for ensuring that all AI-assisted code meets the same standard as hand-written contributions.

Weekly Meeting Expectations​

Each engineer should:​

  • Submit at least one PR per week
  • Participate in team check-ins to share progress
  • Be ready to walk through their PRs
  • Discuss roadblocks, deadlines, and integration needs
  • Update the shared progress tracker with PR links and summaries

Meetings will also be used to:​

  • Review architecture changes
  • Coordinate cross-team efforts
  • Surface any pending schema or package changes for lead review